react clean-code 雑記
1. JSXのショートカット記法を利用する
code: sample.js
...
return (
{showTitle && <h1>this is title</h1>}
);
2. コンポーネントを小さく分ける
1つのコンポーネントに全部詰め込まない
3. カスタムフックを使って、共通コードを抜き出す(DRYの原則)
4. JSXの中からjavascript記法をできる限り切り離す
可読性が悪くなるので、インラインjsはJSXの中で利用しない。
パフォーマンスにも悪影響を及ぼす可能性もある。
5. JSXの中でinline styleも使わない
code: good.js
export default function App() {
const styles = {
main: { textAlign: "center" }
};
return (
<main style={styles.main}>
<Navbar title="My Special App" />
</main>
);
}
6. propsのバケツリレーを避けたいなら、コンテキストを利用する
1. 可読性が悪くなるので、JSXの中で三項演算子は利用しない
code: ng.js
{showTitle ? <p>The condition must be true!</p> : null}
2. 三項演算子の代わりに、「!」を利用する
code: ok.js
{showTitle && <p>The condition must be true!</p>}
{!showTitle && <p>The condition must be false!</p>}
注意.iconこの「1」「2」には落とし穴がある。
評価式の値が「0」だった場合、その0がレンダリングされる罠がある。
その議論が結構白熱してる。
対策としては、評価値がちゃんとbool値を返すように工夫すること
code: sample.js
// NG
{array.length && <p>aaa</p>}
// OK
{array.length !== 0 && <p>aaa</p>}
React Nativeの場合は、「null」を返さないとバグるから気をつけよ。
3. propsにbool値を与える際に、値がtrueの場合はわざわざ指定しなくていい
code: ng.js
<Sample isHungry={true} />
code: ok.js
<Sample isHungry />
4. JSXにインライン関数を紛れ込ませない
5. 状態を変更させるときは、関数を利用して変化させる
code: ng.js
const toggleButton = () => setIsDisabled(!isDisabled)
code: ok.js
const toggleButton = () => setIsDisabled(isDisabled => !isDisabled)
1. オブジェクトは崩して使う
以下のように、オブジェクトの中から利用するpropsを崩して使うといい
code: sample.js
const {name, age} = props
JSXにprops.nameなどと言った冗長な文字が入らないようにする。
JSXは常に見た目を把握やすい状態にしておく。
2. PrettierとESLintを使う
Prettier:コードを適切にフォーマットしてくれる。コードの見た目が統一的になる優れもの。
ESLint:コード内のエラーを見つけてくれる優れもの。
VSCodeを使うなら、必ず拡張を入れておけ
1. モジュールのimportは絶対パスを利用する
2. importの書き方・順番には一貫したルールを設ける
code: sample.js
/* 1. React import statement and standard module dependencies */
import React, { useState, useEffect } from 'react';
/* 2. Standard module dependencies in brackets */
import { useDispatch, useSelector } from 'react-redux';
/* 3. Third party dependencies */
import AppBar from '@material-ui/core/AppBar';
/* 4. Third party dependencies in brackets */
import { useTheme } from '@material-ui/core/styles';
import { IconButton, Badge, Tooltip } from '@material-ui/core';
/* 5. Internal component imports */
import Map from 'components/map';
/* 6. Internal components in brackets */
import { ActionButton, IconButton, FooterButton } from 'components/common/Buttons';
/* 7. Internal functions imports in brackets */
import { getTimezones, getTimezoneName } from 'utils/timezone';
import { getResponses, putResponses } from 'middleware/actions/Response';
/* 8. Internal global variables imports in brackets */
import { DEFAULT_USER, DEFAULT_LOCATION } from 'constants';
/* 9. Internal components within same folder (Relative imports) */
import IconSection from './IconSection';
/* 10. Stylesheet import */
import './style.scss';
3. インラインスタイル乗り用は避けた方がいい ^ スタイルコードはコンポーネントと別ファイルにした方がいい
4. 再利用できるロジックは、グローバルに分離しなさい(DRYの原則)
カスタムフックなどを使って分離すると良い
5. 一貫したコードにするために、命名規則を定めておきなさい
所感.icon状態として扱う変数の命名規則は定めておいた方がいい気がしてるonigiri.w2.icon
1. propsをちゃんと分解して利用しろ
propsじゃなくて{parent, name}的な感じで引数を受け取るようにしよう
2. 似てる・直に関連してるコンポーネントは同じディレクトリでまとめて管理しよう
code: sample
Breadcrumb/
- index.js
- BreadCrumb.js
- BreadcrumbHotdog.js
- ...
3. 標準の命名規則を使用してコンポーネント・フックに名前をつけよう
ex:フック = useXXXX
5. 関数はfunctionよりconstを使え
6. カスタムフック内で定義する必要のない機能は外に配置する。カスタムフックを肥大化させない。可読性をよくしよう。
7. コードに一貫性を持たせろ
例えば、カスタムフックの名付けルールや、クラスの名付けルールなど。
一貫性を持たせることで、コードの読解がよりやりやすくなる。
カスタムフックは基本的にuseXXXとなってるが、もしこのルールを破られると、どれがカスタムフックか人間が分かりにくくなってしまう。
8. 重複する要素をコンポーネント化しなさい
よくあるのは、以下のようなパターン。こういうったパターンの場合は、重複をまとめた方がいい。
code: sample.js
<View>
<Tag my={2} mx={4}>バナナ</Tag>
<Tag my={2} mx={4}>りんご</Tag>
<Tag my={2} mx={4}>グレープ</Tag>
</View>
与えるprop値が一緒なのにめちゃ重複してる。
これは同じファイルでもいいから、まとめといた方がいい。
9. コンポーネントからロジックを剥がして、シンプルにしておく
とにかく複雑化を避ける
10. 1つのコンポーネント or カスタムフックで管理するstateが多くなったら、useReducerの利用を検討する
useReducerで複数の状態を1つのstateにまとめることでコードがすっきりする
stateが多くなってきたら検討してみてはいかが。
11. useEffectのcleanup functionは明示せよ(returnのみで省力しちゃダメ)
12. Prettierを使用する
コードに一貫性を持たせるために、自動でフォーマットしてくれるツールを利用する。
13. <></>を使っていこう。<React.Fragment>の代わりに。
14. コーディングのガイドラインを作っておこう
import記述の順番とか、メソッドの並べ方はアルファベット順とか。
その他
useEffectを使ったら、cleanupをちゃんと実行しよう
以下、onigiri.w2.iconが開発中に思ってたこと
// 関数内では無駄な名前をつけない。利用する側で名前を変えてもらう。
// stateはhashで管理するのか、それとも直接管理するのか。統一した方が綺麗だと思う
// ドメインクラスをそっくりそのまま真似たカスタムフック関数を用意すると綺麗かも
// dispatchはなるべく使わない。ちゃんとした関数を用意してあげる
// reducerを使うタイミングは慎重になった方がいいかも
// アプリ全体で利用する値や状態(state)は、グローバル or コンテキストで扱った方がいい。(dryの原則)
memo.icon
useEffectのcleanupって何?onigiri.w2.icon